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Ya se han revisado los principales elementos que permiten la Programación Orientada a 
Objetos. Sin embargo, hay que señalar que un buen diseño orientado a objetos no sólo consiste 
en utilizar los elementos que se han explicado sin orden ni concierto, sino que juega un papel 
fundamental la experiencia del diseñador. Hay que encontrar las abstracciones adecuadas, 
construir interfaces eficaces y establecer las relaciones necesarias entre ellas. Además, todo ello 
debe hacerse de manera específica para el problema que se pretende resolver, para que la 
programación ofrezca la ventaja de acercarse al dominio del problema. Por otro lado, y también 
debe hacerse de manera genérica, para que sea fácil incorporar nuevos requisitos o resolver 
problemas distintos con los mismos objetos. 

En este tema se esboza el principio del camino que un diseñador de programas orientados a 
objetos debe recorrer. Para ello se introduce el concepto de Patrón de Diseño y se presentan 
unos cuantos de los más importantes. Posteriormente se enuncian algunos principios que 
ayudan a crear un buen diseño. 

8.1. Principales Patrones de Diseño 

Es un hecho que, en general, los diseñadores noveles no son capaces de hacer buenos diseños, 
pues no utilizan adecuadamente las herramientas que la Programación Orientada a Objetos 
proporciona. Mientras, los diseñadores experimentados se caracterizan por conocer multitud de 
buenas soluciones a problemas que ya han tenido que resolver, y reutilizan estas soluciones 
adaptándolas a los nuevos problemas que abordan. 

Los Patrones de Diseño intentan capturar esa experiencia en un conjunto de diseños genéricos 
que sean aplicables a un sin fin de problemas. Según Christopher Alexander, destacado 
arquitecto del siglo XX, “cada patrón de diseño describe un problema que ocurre una y otra 
vez en nuestro entorno, así como la solución a ese problema de tal modo que se pueda aplicar 
esta solución una y otra vez, sin repetir cada vez lo mismo”. Esta descripción es válida también 
para los Patrones de Diseño de la Programación Orientada a Objetos. En los siguientes puntos 
se analizan algunos de los Patrones de Diseño más utilizados. 

8.1.1 Fábrica Abstracta (Abstract Factory) 

Una de las operaciones más comunes al programar con objetos es, lógicamente, la creación de 
los objetos. Sin embargo, esta operación es en si misma un foco de acoplamiento. Cuando 
desde un fragmento de código C invocamos la creación de un objeto de la clase A estamos 
acoplando ese código con el de la clase A. Si posteriormente deseamos cambiar el objeto de 
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clase A por otro de otra clase que cumpla su misma interfaz no podremos hacerlo sin cambiar 
el código C. 

Para evitar este problema se suele delegar la creación de los objetos a otro objeto que se 
denomina fábrica (/actor/). De esta manera desde el código C no creamos el objeto A 
directamente, sino que se lo pedimos a la clase fábrica. Evidentemente, para evitar el 
acoplamiento de la fábrica con el código C, la propia fábrica deberá obtenerse por parámetros. 



Figura 62.- Cada producto concreto se crea desde un constructor especifico. 


Además, el patrón Fábrica permite ocultar los constructores de las clases que crea, de manera 
que solo se puedan crear los objetos a través de la fábrica, impidiendo de esta forma su 
creación de una forma no prevista. 

A continuación se presenta un ejemplo en el que el patrón método de fabricación se utiliza 
para que un sistema gráfico pueda crear diferentes tipos de caracteres. En este caso, la 
separación entre los objetos fábrica y el sistema gráfico permite añadir nuevos tipos de fuentes 
y que el sistema gráfico no deba ser modificado. 
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Figura 63.- En este ejemplo se dispone de un constructor que permite 
crear conexiones con las diferentes bases de datos de los fabricantes a 
un programa de facturación de un taller. 


:AplicacionTaller 


:ModuloFacturacion 


fab:ConexionMarcaAcme 



Figura 


64.- Diagrama de secuencia que muestra el uso de una fábrica para el manejo polimórfico 
de diferentes tipos de conexiones. 
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Existen otros Patrones de Diseño para la creación de objetos. En particular se puede destacar 
al patrón Constructor ( Builder ) y al patrón Método de Construcción (Factory 
Method ). El patrón Constructor es similar al patrón Fábrica Abstracta salvo en que una 
Fábrica suele crear colecciones de objetos, mientras que un constructor solo crea un tipo de 
objetos. Por otro lado, el patrón Método de Construcción se diferencia del patrón Fábrica en 
que son los propios objetos derivados los que crean, mediante un método de construcción, los 
objetos concretos que se necesitan en cada momento. 

Otra alternativa al uso del patrón Fabrica Abstracta consiste en el uso de inyectores de 
dependencias. Son objetos que se programan o se configuran para que devuelvan familias 
concretas de productos cuando cualquier clase de la aplicación le solicita cierto tipo de 
producto. Estas técnicas se apoyan en las características de introspección de Java y pueden ser 
complementarias al uso de Fábricas Abstractas. 

8.1.2 Adaptador o Envoltorio (Adapter o Wrapper) 

El patrón Envoltorio se utiliza cuando se desea que una clase utilice otra aunque que no 
cumple cierta interfaz obligatoria. Por ejemplo, en el diagrama adjunto la clase Cliente solo 
puede utilizar objetos que cumplan la interfaz Interf azAmiga, pero se desea utilizar sobre la 
clase Extraña. Para ello, se crea la clase Envoltorio, que contiene un objeto de la clase 
Extraña pero que implementa la interfaz Amiga. De esta forma, la clase Usuaria utiliza, 
indirectamente, la clase Extraña. 



Figura 65.- El cliente accede a la clase extraña utilizando una interfaz que conoce y que 

envuelve a la clase extraña. 

Este patrón se utiliza cuando deseamos almacenar un tipo primitivo de Java en un derivado de 
Collection. Por ejemplo, supongamos que deseamos almacenar un int en un Vector. 
Como los enteros no son elementos de la clase Object es necesario envolverlos en otra clase 
que contenga el entero y que, al derivar de Ob j ect, sí pueda ser insertada en el vector. Por eso, 
y por otras razones, en Java existen clases como Integer, Float, Boolean o Character 
que son envoltorios de los tipos primitivos. 
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Figura 66.- En este caso el adaptador es Integer y adapta al tipo primitivo 
int para que pueda ser usado como un Ob j ect. 


8.1.3 Decorador ( Decoratot ) 

El patrón Decorador permite añadir nueva funcionalidad a una familia de componentes 
manteniendo la interfaz del componente. El siguiente diagrama ilustra este patrón. La clase 
Componente es abstracta, la clase ComponenteConcreto implementa un comportamiento 
determinado. La clase Decorador contiene un Componente en su interior. Cuando se solicita 
una operación al objeto de la clase Decorador esta la deriva al Componente que contiene. 
Las clases derivadas de Decorador son los verdaderos Decoradores que implementan una 
nueva funcionalidad añadida al Componente que contienen. 



Figura 67.- El decorador A añade cierta funcionalidad a cualquier componente manteniendo la 

interfaz de tal componente. 
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Por ejemplo, el patrón Decorador se puede utilizar, para añadir cifrado o compresión a las 
clases de escritura en Streams. Así, la clase de la que derivan todas sería Writer. Un Writer 
concreto, por ejemplo, es el FileWriter. La clase WriterDecorator se encarga de 
redirigir las llamadas a los diferentes métodos del Writer hacia el Writer que contiene 
dentro. Finalmente, las clases EncriptWriter y ZipWriter implementan cierta operación 
sobre el flujo de salida que se dirige hacia el Writer concreto contenido en el Decorador. 



Figura 68.- Decorador para añadir un buffet y compresión a un Writer. 


El siguiente Diagrama de Actividad muestra el comportamiento esperado para este patrón. 



Figura 69.- La escritura pasa primero por el decorador (el ZipWriter), el cual decide cuándo 
enviarla al elemento decorado (el FileWriter en este caso). 
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8.1.4 Composición ( Composite) 

Es muy común la necesidad de crear grafos dirigidos en los que cada nodo puede representar 
ciertos elementos de un modelo informático. Estos grafos suelen crearse utilizando el patrón 
Composición. Este patrón se puede definir como jerarquías de objetos que comparten una 
interfaz y tales que algunos de los objetos pueden formar parte de otros. La siguiente figura 
describe este patrón. Obsérvese que tanto los objetos de la clase Hoj a como los de 
Compuesto cumplen la interfaz Componente, pero los de clase Compuesto además puede 
contener dentro otros objetos de la clase Componente. 



Figura 70.- La clase componente proporciona la interfaz común. Las clases derivadas pueden 
ser de dos tipos: compuestos (que a su vez agrupan a otros componentes) o simples hojas. 

Por ejemplo, en una jerarquía de componentes de dibujo puede ser importante que todos los 
elementos que se puedan dibujar compartan cierta interfaz, pero además también es 
importante que unos elementos puedan formar parte de otros (los objetos línea forman parte 
del objeto cuadrado). 

8.1.5 Iterador ( Iteratot ) 

Habitualmente, cuando se dispone de una colección de objetos se desea recorrerlos. El patrón 
Iterador permite definir objetos para realizar esta tarea. Un objeto iterador es una especie de 
apuntador que se puede iniciar apuntando al primer elemento de una colección y que puede 
desplazarse hasta el último elemento de la misma. 

Java dispone de la interfaz Iterator, la cual está implementado por las diferentes clases de 
Collection. En realidad, estas clases son fábricas de iteradores que permiten recorrerlas. 
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Figura 71.- El iterador concreto permite recorrer el contenedor concreto. 


8.1.6 Estrategia ( Strategy ) 

En cualquier programa es habitual disponer de un conjunto de algoritmos que comparten 
alguna propiedad, como que pueden ejecutarse indistintamente sobre unos datos de entrada o 
que sean de determinado tipo. Ejemplos de tales familias serían las funciones matemáticas 
(seno, coseno, raíz...) o los filtros gráficos de un programa de dibujo. El patrón Estrategia 
permite organizar dichas familias de algoritmos, de manera que compartan una interfaz para 
que luego los clientes de dichas clases puedan utilizarlos indistintamente. 



Figura 72.- Los objetos de la clase de contexto que acceden a la familia de algoritmos los 
hacen de forma abstracta, sin importarles el algoritmo específico que se está utilizando. 

Un ejemplo de uso del patrón Estrategia puede ser la implementación de los diferentes 
algoritmos de ordenación de una lista de números (ver Figura 73). Gracias al patrón Estrategia 
el usuario del contexto puede modificar su criterio de ordenación de forma dinámica. 
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Figura 73.- Un usuario puede utilizar cualquiera de los algoritmos que cumplan la 
interfaz de ordenación a través del objeto Contexto. 

8.1.7 Comando ( Command) 

Este patrón encapsula las operaciones que realiza un objeto de forma que éstas sean a su vez 
objetos que cumplen una misma interfaz. Esto permite realizar, de manera sencilla, tareas 
como: agrupar o encolar operaciones, deshacer operaciones y parametrizar otros objetos con 
dichas operaciones de forma sencilla. Además, fomenta que añadir nuevos comandos sea una 
tarea simple y aislada. El Diagrama Estático de Clases adjunto describe su estructura estática y 
el Diagrama de Secuencia de la Figura 75 explica su comportamiento dinámico. 

El patrón Comando se podría utilizar, por ejemplo, para ordenar los comandos que se pueden 
ejecutar desde un intérprete de consola (ver Figura 76). Si el interprete utiliza los comandos 
solo a través de la interfaz común, sin conocer en cada momento el comando concreto que se 
está ejecutando, una de las ventajas que se obtienen consiste en que el número de comandos 
puede crecer sin modificar dicho interprete. 
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Al llamar a ejecutar se ejecuta 
Receptor -> Accion() 


Figura 74.- Diagrama de clases del patrón Comando. 



Figura 75.- El cliente crea los comandos y los asocia al ejecutor. Más tarde, ejecuta el 
comando que corresponda. Dicho comando, que conoce al receptor de su orden, ejecuta la 
acción asociada al receptor que conoce . 


- 150- 

Vélez, S. J., Peña, A. A., & Gortázar, B. P. (2011). Diseñar y programar, todo es empezar: Una introducción a la programación orientada a 
objetos usando uml y java. Retrieved from http://ebookcentral.proquest.com 
Created from pucesp on 2020-01-14 12:52:12. 














Copyright© 2011. Dykinson. All rights reserved. 


Diseñar y Programar todo es empezar 



Figura 76.- El objeto de clase Interprete sólo necesita conocer la interfaz de la clase 
ComandoShell. En este caso, el sistema operativo sería el receptor y el interprete seria el ejecutor. 


8.1.8 Observador ( Observa ) 

Este patrón crea una relación entre objetos en la que uno de ellos es observado por el resto, de 
manera que cuando el objeto observado cambia el resto puede automáticamente realiza alguna 
acción. En la Figura 77 se presenta el Diagrama Estático de Clases de este patrón. 
Dinámicamente, cuando cambia el estado del objeto ElementoObservadoConcreto se 
ejecuta el método avisar (), el cual llama al método actuar () de cada observador. 



Figura 77.- El Elemento observado avisa a los observadores cuando su estado cambia. 


El patrón Observador lo utiliza Java para implementar el código que se ejecuta cuando un 
objeto de tipo componente cambia de estado. Java crea un objeto de clase Listener 
(escuchador en vez de observador) para cada operación que se realiza con un botón (elemento 
observado en este caso). Ese objeto Listener contiene el código que se ejecuta al realizar la 
operación sobre el botón. Así, cuando un usuario pulsa un botón y el estado del componente 
botón cambia el Listener que lo observa es capaz de ejecutar cierto código. 
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8.2. Algunos principios útiles en POO 

En este apartado se presentan algunos principios que se deben seguir al realizar el diseño de un 
programa orientado a objetos. 

8.2.1 El principio abierto-cerrado 

Bertrand Meyer estableció el siguiente principio en 1998: 

Todas las entidades de software (clases, módulos, funciones...) deben estar abiertas para 
extensiones y cerradas para modificaciones. 

Este principio intenta evitar que un cambio en un programa produzca una cascada de cambios 
en módulos dependientes. Los programas que se hagan siguiendo este principio deberán tener 
vías para que cuando los requisitos cambien podamos extender el comportamiento añadiendo 
nuevo código (abierto a extensión), pero sin cambiar el código que ya funciona (cerrado a 
modificación). 

La mejor forma de conseguir que un código siga este principio consiste en fomentar el uso de 
clases abstractas o interfaces en las relaciones entre objetos. 



(a) (b) 

Figura 78.- En una relación entre clases debe preferirse siempre el esquema (b) al (a). 

Como consecuencia del principio abierto-cerrado aparecen dos corolarios: 

• Todas las propiedades deben ser privadas.- Si una propiedad no es privada ningún 
módulo externo que dependa de esa variable podrá estar cerrada a modificaciones 
cuando por ejemplo se cambie el comportamiento de la propiedad o se elimine. 
Además cualquier modulo externo que utilice la variable de una forma no esperada 
por el resto de módulos clientes de la variable hará que éstos fallen. 

• Evitar la identificación dinámica (uso del casting de referencias y de instanceof). Si 
un módulo necesita identificar el tipo de un objeto en tiempo de ejecución para tomar 
una decisión, este módulo podría no estar cerrado a modificaciones que ocurrirían 
cuando apareciesen nuevas clases de objetos. 

8.2.2 El principio de Liskov 

Barbara Liskov estableció el siguiente principio: 
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Toda función que utiliza referencias a un objeto de una clase A debe ser capaz de usar objetos 

de clases derivadas de A sin saberlo. 

Este principio ofrece un camino para que el código sea más fácil de extender, ya que fomenta 
la creación de métodos que pueden funcionar con clases que aún no han sido creadas. 

8.2.3 El principio de segregación de interfaces 

Robert C. Martin estableció el siguiente principio: 

Es preferible varias interfaces específicas que una única interfaz general. 

Seguir este principio minimiza el impacto del cambio de una interfaz, ya que no existen grandes 
interfaces de las que dependen multitud módulos. 

8.2.4 Maximizar el uso de clases inmutables 

Las clases inmutables son aquellas cuyos objetos no cambian de estado una vez creados. Por 
ejemplo, String es una clase inmutable. Con objeto de forzar este comportamiento todas las 
propiedades de la clase deben ser finales. La inmutabilidad simplifica enormemente la 
implementación de una clase. Además hace posible el uso de un mismo objeto desde 
diferentes threads simultáneamente sin usar mecanismos de exclusión. Evidentemente, es 
imposible que ciertas clases, las que mantienen el estado de un programa, sean inmutables. 

8.2.5 Preferir composición frente a herencia 

Ya se ha comentado que la herencia rompe la encapsulación. Tal y como se ha comprobado 
con el patrón Decorador, siempre es posible obtener un comportamiento similar a la herencia 
utilizando composición. Para forzar esta preferencia es una buena práctica siempre definir las 
clases y los métodos como finales, evitando de esta forma que se pueda heredar de ellos. Solo 
en los casos en los que la herencia se planifique, como en el patrón Estrategia, se debe omitir el 
modificador final. 

8.2.6 Principio de responsabilidad única 

Una clase debe tener una única responsabilidad y dicha responsabilidad debe estar 
completamente encapsulada en dicha clase. Robert C. Martin define este principio como sigue: 

Una clase debe tener un único motivo para cambiar. 


8.2.7 Eliminar duplicaciones 

Andy Hunt denominó a este principio DRY ( Don ’t repeat your self). Siempre que existe una 
duplicación se debe a que no se ha abstraído lo suficiente. Probablemente la duplicación se 
pueda eliminar con la introducción de un nuevo método o una nueva clase. 

La mayoría de los patrones que han aparecido en los últimos 15 años han sido creados para 
eliminar las duplicaciones en el código. 
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8.2.8 Principio de inversión de dependencia 

Los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben 
depender de abstracciones. 

8.2.9 Preferir el polimorfismo a los bloques if/eise o switch/case 

Normalmente, el uso de uno de estos bloques indica que la clase está rompiendo el principio 
de responsabilidad única. Si en una clase tenemos un bloque if/else, esa clase unas veces 
tendrá una responsabilidad (cuando entre por la rama if) y otras veces tendrá otra diferente 
(cuando entre por la rama el se). Prácticamente la totalidad de los bloques if/else y de los 
bloques switch/case pueden reemplazarse mediante polimorfismo. 

8.2.10 Conclusiones 

El descubrimiento de estructuras comunes (patrones) en diferentes tipos de programas, puede 
ayudar a identificar buenas estructuras que se pueden reutilizar en diferentes implementaciones. 
Es por ello que, desde aquí, se anima al lector a que profundice en los conocimientos de 
Programación Orientada a Objetos que acaba de adquirir mediante este camino. 

8.3. Lecturas recomendadas 

“Patrones de Diseño”, Erich Gamma y otros, Addison Wesley, 2002. Este libro es la principal 
guía de referencia en cuanto a patrones de diseño. 

“Piensa en Java. Eckel”, 2 a Edición, Addison Wesley, 2002. Su anexo C contiene un gran 
compendio de principios y buenas prácticas. 

“Clean Code”, Robert C. Martin. 

“Design Principies and Design Patterns”, Robert C. Martin, www.objectmentor.com, 2000. 

8.4. Ejercicios 

Ejercicio 1 

Realice el diseño de un programa que implemente una Hoja de Cálculo. 

El programa contendrá en cada momento un libro abierto el cual se compondrá de varias 
hojas. A su vez, cada hoja contiene celdas en cada una de las cuales se pueden disponer texto o 
fórmulas. 

El texto consistirá en un conjunto de caracteres alfanuméricos entre comas simples. Las 
fórmulas se compondrán de constantes numéricas (2, 3.14...), operadores simples (+-*/) y 
funciones predefinidas (eos, sen, tg ...). El anexo 1 describe la gramática que deberán seguir las 
fórmulas. 

Las celdas se disponen en forma de retícula, formada por filas y columnas. Cada columna y 
cada fila estará etiquetada por un número consecutivo. Podrá haber un número indeterminado 
de filas y columnas, aunque en pantalla sólo se podrán ver simultáneamente un subconjunto del 
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total. En todo momento habrá siempre una hoja activa, de manera que las operaciones con las 
celdas se referirán siempre a una hoja concreta. 

La interacción con el programa, que podrá ser en modo texto, consistirá en la escritura de 
instrucciones mediante el teclado. Así, el sistema ofrecerá un prompty el usuario podrá escribir 
una instrucción, la cual se ejecutará tras presionar la tecla Return. El anexo 2 describe el juego 
de instrucciones que deberá admitir el programa. 


Fórmulas 

Las fórmulas que se requiere que contengan las celdas son las generadas por la siguiente 
gramática en notación BNF: 


<FÓRMULA> : 
<REF> 

::= <FÓRMULA> <0PERAD0R> <FÓRMULA> | <REAL> 

| <FUNCIÓN>(<F0RMULA>) | 

<0PERAD0R>: 

: := +1-1*1/ 


<FUNCIÓN> : 

: := sen | eos | tg 


<REF> ::= 

celda(<NÚMER0,NÓMER0>) 


<REAL> ::= 

<NÚMER0>.<NÚMER0> | <NÚMER0> 


<NÚMER0> :: 

:= <DÍGIT0> | <DÍGIT0> <NÚMER0> 


<DÍGIT0> : : 

:= 0 :| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 j 9 



Donde: 


cos(<fórmula>).- Calcula el coseno de una fórmula. 
sen(<fórmula>).- Calcula el seno de una fórmula. 
tg(<fórmula>).- Calcula la tangente de una fórmula. 
celda(<fila,columna>).- Devuelve el valor contenido en la celda . 

Juego de instrucciones 

Las órdenes que se desea que tenga la hoja de cálculo está compuesto por las siguientes 
instrucciones: 

CrearLibro.- Esta operación elimina las hojas de cálculo actualmente abiertas y crea 3 hojas 
vacías etiquetadas como hojal, hoja2 y hoja3. Además se pondrá la hojal como hoja activa. 

CrearHoja <nombre>.- Crea una hoja dentro el libro actual y la dispone como hoja actual. 
Los nombres de las hojas no podrán contener espacios, además no se podrá crear una hoja si 
tiene el mismo nombre que otra que ya exista. 

BorrarHoja <nombre>.- Borra una hoja dentro el libro actual. Si era la hoja activa dispone 
otra como activa. Si no quedan mas hojas automáticamente crea una nueva. 

Renombrar <nombre hojaXnuevo nombre>.- Esta operación renombra una hoja. 
Los nombres de las hojas no podrán contener espacios, además no se podrá crear una hoja si 
tiene el mismo nombre que otra que ya exista. 
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Capítulo 8 


Patrones y principios de diseño 


HojaActual <nombre>.- Permite seleccionar cual es la hoja actual. 

Celda(<fila>,<columna>) = [<formula> | <'texto'>].- Permite asignar un valor nuevo 
a una celda. Si el valor es de tipo alfanumérico deberá ir entre comillas simples, en otro caso 
corresponderá a una fórmula que seguirá la gramática del anexo 1. 

Así, para asignar un valor a una celda se utilizará la siguiente notación: 

Celda(<fila>,<columna>)='texto' 

Celda(<fila>,<columna>)=fórmula 


Por ejemplo: 


Celda(1,1)='Radio' 

Celda(1,2)=25 

Celda(2,1)='Perímetro' 

Celda(2,2)=Celda(1,2)*3.14*2; 


Mostrar(<fila>, <columna>).- Muestra por pantalla el contenido de las celdas 
correspondientes a 7 columnas y 10 filas a partir de la casilla indicada por el par (<fila>, 
<columna>). 

Cada columna y cada fila estará encabezada por un número consecutivo que la identifica. 
Además, todo el texto estará encabezado por el nombre de la hoja. 

Se utilizará exactamente 9 caracteres para presentar el contenido de cada celda y un espacio 
como separación con la celda siguiente. Con el fin de que aparezca ordenado el contenido de 
cada celda se completará con espacios cuando el tamaño sea menor y se recortará el contenido 
por la derecha cuando el tamaño sea mayor. 

Si una celda contiene texto alfanumérico se presenta tal texto en el lugar asignado. 

Si una celda contiene una fórmula se presentará, en el lugar asignado, el resultado de la 
aplicación de la fórmula en ese momento y no el texto de la fórmula. 


Por ejemplo, Mostrar (0,0) muestra desde la celda (0,0) hasta la celda (6,9) presentaría: 


Hoja: 

Hojal 





01 11 

2 I 

31 

4 | ... 

0 





1 

Radio 

25 



2 

Perímetro 

157 



3 






Deberá detectarse la aparición de referencias circulares, por ejemplo almacenando si una celda 
ya ha sido calculada, para impedir que vuelva a intentarse su cálculo. 

Se devolverá el texto ERROR si una fórmula resulta en un error, por ejemplo si se detecta 
referencia circular al calcular el valor de una celda. 
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Cargar.-<"ruta nombre de fichero">.- Permite cargar un libro de disco. 

Salvar <"ruta y nombre de fichero">.- Permite guardar un libro con todas sus hojas y 
el contenido de sus celdas a disco. 
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